Verifying Software Signatures

Kicksecure ™

Download

On Computer USB Installation Intel / AMD64 ARM64 Raspberry Pi PPC64 Windows (VM) Mac Linux (VM) VirtualBox (VM) Qubes (VM) KVM (VM) Debian morph to Kicksecure More options Source Code

About

Overview Features Why Open Source? Project Activities Contributors Mission & Vision

Docs

Documentation FAQ Troubleshooting

Community

Forums Forum Best Practices Contribute

Support

Self Support First Policy Search Engines, Docs and AI Support (Limited) Reporting Bugs Contact (Restricted)

Tools Upload file Special pages Recent changes Print Version Page meta What links here Related changes Page information

Page Read Edit History Move Protection Unwatch Watch Delete Purge

User Preferences Watchlist Contributions Logout Create account Login

Donate

Download Issues Documentation Signing Key Previous page: Download Issues Index page: Documentation Next page: Signing Key Verifying Software Signatures

• Verifying Software Signatures
• OpenPGP
• Air Gapped OpenPGP Key
• Signify
• Codecrypt
• Authenticode
• Kicksecure Digital Signature Policy

Digital signatures are a key component of online security, providing a way to verify the authenticity and integrity of software. But what does that really mean, and why should you care? This guide is here to answer those questions. We'll walk you through the process of software signature verification, help you understand the strengths and limitations of digital signatures, and navigate you through the potential pitfalls. Whether you're a seasoned tech professional or just starting to dip your toes into the world of digital security, this guide has something for you.

Introduction

Digital signatures are a digital tool to ensure the authenticity of software and the absence of any third party modifications. These digital signatures and the habit of always verifying these signatures is critical to enhance system security.

It's crucial to avoid installing unsigned software and instead following these best practices:

• Always opt for verifiable software that allows for confirmation of signing keys and signatures. This ensures the software you're installing is authentic and hasn't been tampered with.
• Utilize mechanisms like apt upgrades that simplify and automate the verification process. This makes it easier to maintain system security without requiring extensive technical knowledge.

Risks of Not Verifying Digital Signatures

Neglecting to verify digital signatures can expose users to a variety of risks. While the "Attacks in the Wild" section provides specific instances of these risks, it's important to understand the general implications of not adhering to this security practice:

• Compromised Software: Without verification, you may unknowingly install compromised software. This could include malware, spyware, or other malicious code that can harm your system, steal sensitive information, or perform unwanted actions.
• Loss of Data Integrity: Digital signatures ensure the integrity of the software, confirming that it hasn't been tampered with since it was signed. Without verification, there's no guarantee that the software you received is the same as the software that was originally distributed.
• Identity Spoofing: Digital signatures authenticate the identity of the software provider. Without verification, you may fall victim to identity spoofing, where an attacker poses as a legitimate software provider to distribute malicious software.
• System Vulnerabilities: Unverified and potentially compromised software can introduce vulnerabilities into your system, making it a target for further attacks.
• Loss of Trust: On a broader scale, failing to verify digital signatures can erode trust in software distribution channels. If users can't be sure that the software they're receiving is genuine and untampered, they may be less likely to use these channels in the future.
• Related: Essential Security Guide Introduction chapter Motivation.

In summary, verifying digital signatures is a crucial step in maintaining the security, integrity, and trustworthiness of software and should not be overlooked.

Unfixable Documentation Usability Issue

Could you provider easier digital signature verification documentation please?Common user support request. (Paraphrased.)

• Inherently difficult topic: Non-technical users often struggle with these concepts. This is complicated stuff, and as early as 1999 the Why Johnny Can’t Encrypt: A Usability Evaluation of PGP 5.0 paper was published.
• Simple documentation impossible: There seems to be literally no way to make the documentation on that topic uncomplicated.
• Documentation has limits: There are some things which are so complicated they cannot be learned through documentation alone. Read a book and become a heart surgeon? No way. Become "at least" a general practitioner? Also no way. Learning by doing, sitting together in the office of a general practitioner for years: can doctor skills be learned through on-the-job training, listening, observing, and imitating? Also no way. In many countries it requires about 12 years of study. Now, maybe that could be compressed, or some bright minds could learn it faster, but it still cannot be compressed to 1 year. In any case, there is no way to "write simple documentation".
• More realistic comparison: Now that's a bit far-fetched. Learning the digital software verification of OpenPGP signatures probably won't take years of study. A guesstimate would be that it takes several hours or days and may require a teacher. (Find a Teacher) There may be OpenPGP courses and cryptoparties (at least these used to exist). This illustrates that there is no way to have simple documentation for this complex topic.
• Further discussion: Whonix forum discussion: expkeysig error gpg key whonix

Verification Commands Cannot Replace Key Verification

Why not just provide the verification commands or a script to copy and paste?Common user support request. (Paraphrased.)

• Copy and paste is not enough: If asking over https/onion (such as in forums or by e-mail) is required, then copying and pasting these commands is not helpful because the answer is complicated.
• Same problem during OS installation: The same challenges exist when initially installing Debian (non-Qubes), Fedora, Ubuntu, Qubes, etc.
• Verification must be independent: In other words, to gain the security benefits of key verification, it is necessary to know how to perform key verification without relying on TLS/onion, such as by asking forums, AI, etc.
• Commands do not add trust: Commands could be provided that someone could copy and paste without their own technical understanding, or a script could even be provided. But using these commands is no more secure than copying the signing key without verification, and a script would actually be even less secure.
• If it must be asked, it is likely insecure: In other words, if it is necessary to ask how to do it, it is likely not possible to do it securely.
• Similar conclusion by Tails: The Tails project reached a similar conclusion. See Appendix.

Verification Procedure

In this chapter we will explain the verification procedure. Please read the warnings below too. This is sort of a cheat sheet of overall warnings regarding the verification process that you should internalize.

Important: Do not proceed if verification fails! This could risk using infected or erroneous files. The purpose of verification is to ensure file integrity.

Remember to check the GPG signature timestamp. For instance, if you previously saw a signature from 2023 and now see one from 2022, this could indicate a potential rollback (downgrade) or indefinite freeze attack.

Remember: OpenPGP signatures sign the contents of files, not the file names themselves.

Checking Digital Fingerprints of Signing Keys

Warning: Only install software after verifying the key's fingerprint and ensuring good signatures for files/repositories.

The first critical step in verifying software legitimacy is confirming the authenticity of the signing key, which requires inspecting the key fingerprint. Always perform this operation before importing keys or placing trust in OpenPGP output when verifying files or repositories.

Our standard advice is to carefully obtain copies of the OpenPGP fingerprint from multiple secure websites and to use other authentication systems to check for a match. In this context, "other authentication systems" refers to:

• Utilize The OpenPGP Web of Trust.
• Verify the key against different keyservers.
• Use various search engines to search for the fingerprint.
• Employ various VPNs and proxy servers.
• Access different Wi-Fi networks (work, school, internet cafe, etc.).
• Request people to post the fingerprint in various forums and chat rooms.
• Check against PDFs and photographs where the fingerprint appears (e.g., slides from a talk or on a T-shirt).
• Repeat all of the above from different computers and devices.
• See also Bootstrapping OpenPGP keys from the web.

Checking Digital Fingerprints of Signed Software

Before you can safely verify file signatures with the signing key, ensure the following prerequisites are met:

1 The correct signing key pair has been downloaded.

2 The signing key's fingerprints have been checked against multiple sources.

3 The key pair has been imported. For example:

user@host:~/Downloads$ gpg --import KEY
gpg: key 61B7B526D98F0353: 24 signatures not checked due to missing keys
gpg: key 61B7B526D98F0353: public key "Mozilla Software Releases <release@mozilla.com>" imported
gpg: Total number processed: 1
gpg:               imported: 1
gpg: no ultimately trusted keys found

4 The software package intended for installation has been downloaded.

5 The accompanying signature file for the software package (.asc files are GPG signatures) has been downloaded.

For example, to check the file signature for Firefox v97.0.1, downloaded directly from the Mozilla Firefox website, run the following command in a terminal:

gpg --verify firefox-97.0.1.tar.bz2.asc firefox-97.0.1.tar.bz2

The OpenPGP output should show a "good signature", with the primary key fingerprint matching the one you verified earlier. For example:

gpg: Signature made Wed 16 Feb 2022 06:52:12 PM GMT
gpg:                using RSA key 4360FE2109C49763186F8E21EBE41E90F6F12F6D
gpg: Good signature from "Mozilla Software Releases <release@mozilla.com>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: 14F2 6682 D091 6CDD 81E3  7B6D 61B7 B526 D98F 0353
     Subkey fingerprint: 4360 FE21 09C4 9763 186F  8E21 EBE4 1E90 F6F1 2F6D

You can now safely install the software. If the output states "bad signature", then remove the files and digital signatures and download them again.

Common Misconceptions

What Digital Signatures Prove

It's important to understand that using digital signatures to verify the trustworthiness of software isn't infallible. Digital signatures increase the likelihood that no backdoor was introduced by a third party during transit, but they don't guarantee the software is entirely "backdoor-free". Below is a summary of what digital signatures can and can't prove.

Digital Signatures Properties

Property	Description
Digital Signatures Prove	A signature was made by someone with access to the private key. The file contents haven't been tampered with, preserving integrity. May indicate the given file is authentic.
Digital Signatures do not Prove	Any other property, for example, that the file isn't malicious. Nothing prevents a person from signing a malicious program. Digital signature or not, for example in the case of intentional breakage, supply chain attacks: Dev corrupts NPM libs 'colors' and 'faker' breaking thousands of apps backdoors: bitcoin copay wallet “direct” backdoor "If more than 100 BTC, steal it. Otherwise, don’t bother." a digital signature would not have helped. That the persons signing the file are inherently trustworthy, for example: Debian, Kicksecure developers and so on -- but trust must be eventually placed in someone.

Verifying all files downloaded from trusted vendors eliminates threats from server compromises, dishonest staff at hosting companies or ISPs, Wi-Fi attacks, and so on. This is because tampered files will produce bad digital signatures, provided the public keys used for signature verification are the authentic, original ones (see below).

System Security Level

System security can be categorized into one of three levels, from strongest to weakest:

• Always use software signatures verification: Software signatures are consistently verified using OpenPGP, codecrypt, APT, or similar mechanisms.
• Always use TLS: Files are always securely downloaded over TLS.
• Plaintext.

If you've ever installed or started software without successfully verifying its signatures, your system's security level drops from the OpenPGP standard to either TLS or plaintext.

Without implementing a Disaster Recovery Procedure, it's impossible to elevate the security level of a machine or VM (for example, from TLS to the OpenPGP standard).

If you agree with the Kicksecure view that Transport Layer Security (TLS) provides weak protection, then you must verify software signatures consistently and without exception.

Conceptual Challenges in Digital Signatures Verification

Verification of software digital signatures presents many educational challenges. Often, implicit assumptions are made in the relevant literature, which are seldom spelled out. Without proper education, it's unrealistic to expect the majority of users to successfully verify software signatures and simultaneously notice attacks by advanced adversaries.

When digitally signed software is available, most websites simply state that the signing key should be downloaded to verify software signature(s). This approach has limited usefulness and kicksecure.com is not alone in this regard -- the same is true for any software that provides software signatures.

The responsibility of verifying software signatures falls entirely on users, and cannot be offered by vendors who make software and associated signatures available for download. This is because the threat model of software signature verification is closely linked with the system security level; this section attempts to make this explicit.

Threat Model Assumptions

In this threat model, signing keys and software signatures are considered to provide a higher security level. Conversely, everything the user can see on a website (including instructions) is on a lower security level because (OpenPGP) signed websites do not yet exist. Moreover, TLS provides a lower security level than verification of digital software signatures.

Consider an example of signed software available on a random website secured by TLS (in this case, TLS vs non-TLS doesn't matter). Due to the software's file size and economic constraints, it's impossible to host the software downloads on the same server. Instead, downloads are offered on a mirror network operated by third parties. In such a scenario, it could be argued that mirrors are less trusted than the main project website. If the main website offered a signing key, but a malicious file was shipped by a third-party mirror, then this could be detected if software signature verification was utilized by the user.

In other cases, the software downloads, signing key, and software signatures are all provided by the same server over TLS; this is the situation for Kicksecure and other projects. While this may appear more secure than the first example, no project can guarantee that its server will never be compromised; see Distrusting Infrastructure for further details.

The preceding discussion makes it clear that it's unwise to blindly trust whatever a project website says about software signature verification. Relevant threat model questions include:

• What if the website I am currently viewing is already compromised?
• What if a malicious third party has already modified instructions concerning how to verify signatures or which signing key should be used?

Also, after compromising a project web server, advanced adversaries are capable of showing fake website contents to specifically targeted users.

Potential Adversary Attacks

Competent adversaries are capable of various attacks, including malicious modifications of a project website. Consider the following vectors:

• Removal of any mention of software signature verification and replacement of software downloads with malicious counterparts.
  • Users unfamiliar with software verification would fail to notice this, leading to compromise.
  • Users who already understand the threat model of digital software verification and enforce the security level "always use software signatures verification" would ask for software signatures and remain safe.
• Insertion of false information such as "From now on, software signatures are no longer required. This process is now automated, because ...".
  • Gullible users would believe this statement and be compromised.
  • Diligent users would search for a digitally signed message by the vendor confirming this change. If it was not found, they would report the issue and remain safe.
• Replacing the genuine signing key and software signatures with a signing key and software signatures created by the adversary.
  • Users who did not previously receive the signing key and who did not do further research on the plausibility of having received the correct signing key would fail to notice this and be compromised.
  • Diligent users would follow the recommendations in earlier chapters on this page and therefore stay safe.

To counter these threats, user intelligence and due diligence is necessary as a sanity check.

Due to the complexity of this issue and very low user awareness, it is unlikely the majority of users are enforcing the "always use software signatures verification" security level. To date, the author of this section has not seen the security level concept explicitly described elsewhere, probably because the relevant information is not widely known. Unfortunately, the existing tools used for manual verification of software signatures have poor usability and better technical solutions that are required do not exist.

Appendix

Bold added.

OpenPGP signatures

Unless the user knows how to verify the signing key through the OpenPGP Web of Trust, this technique ultimately relies on a correct download of the signing key and signature, and thus on HTTPS.Tails: Design: Download verification

OpenPGP verification instructions

We removed the instructions to verify downloads with OpenPGP because:

Without advanced knowledge of OpenPGP, verifying with OpenPGP provides the same level of security as the JavaScript verification on the download page, while being much more complicated and error-prone.

None of our personas would have enough knowledge of OpenPGP to use the OpenPGP Web of Trust with confidence.

Providing basic (and never exhaustive) instructions has proven to be very time consuming to our help desk and technical writers. See #17900.

We still explain how to verify our signing key using the OpenPGP Web of Trust in the installation instructions from Debian, Ubuntu, or Mint using the command line and GnuPG because Debian derivatives come with trusted OpenPGP keys that can be used to create a path to our signing key.

Injected [are doing] as this is a likely interpretation to improve readability.

People doing the OpenPGP verification without really knowing what they [are doing] is still very heavy on Help Desk and pretty heavy on Technical Writing.

Still, our download page cannot be a complete course on OpenPGP and Web-of-Trust verification. We should take a step back and reflect on the broader strategy:

• Shall we remove these instructions entirely?
• Shall we move them to a different place?
• Shall we find better ways of telling people that they are on their own?

This is on our 2020-2022 roadmap.Tails: Development ticket: Remove our OpenPGP verification instructions

Information Security Level

The information security level (similar to the system security level) can be categorized into one of three levels. From the strongest to the weakest, these are:

• Signatures Verification: Signatures are verified with OpenPGP, signify, codecrypt, Authenticode, or similar mechanisms.
• TLS: Information was received over TLS.
• Plaintext.

Other properties and categories are also conceivable, such as:

• Third-party server not involved or cannot tamper with information due to security by design.
• Offline signing key.

Attacks in the Wild

Cryptocurrency Theft via Compromised Binaries

Towards the end of 2019, a malware attack threatened the security of Monero cryptocurrency users, leading to significant unauthorized fund transfers. Binaries for the Monero cryptocurrency (CLI) wallets were compromised by a malicious party and uploaded to a popular third party software download provider. Checking the signature as provided by the Monero team and realizing that the file was not authentic would have saved a lot of users from having their funds stolen.

• Security Warning: CLI binaries available on getmonero.org may have been compromised at some point during the last 24h.
• Warning: The binaries of the CLI wallet were compromised for a short time
• Wrong hashes (from getmonero.org)
• Monero download site and binaries compromised

Counterfeit Tor Browser Attack

The following instance exemplifies the potential risks of installing unsigned software. A recent cyber-attack utilized a "trojanized" Tor Browser to spy on users and steal Bitcoin. The orchestrated attack involved several key components:

This case emphasizes the potential dangers of installing unsigned software, resulting in loss of anonymity and financial theft in this instance. Had the victims only installed signed Tor Browser software from trusted sources after: verifying the correct key pair, confirming the key's fingerprints, and checking the consistency of the signature file for the software package, they could have sidestepped this scam entirely.

• Advertisements for the counterfeit Tor Browser were disseminated in Russian forums dedicated to topics such as privacy, circumvention of censorship, darknet markets, and cryptocurrencies.
  • Messages included promises to bypass Russian censorship bodies and to overcome CAPTCHAs.
  • Users were directed to bogus domains for downloading the Tor Browser (tor-browser.org and torproect.org), rather than the official website: torproject.org.
• After accessing the fraudulent websites, users were falsely alerted that their Tor Browser was outdated. Users who fell for this ruse were redirected to another website offering an installer.
• The malicious version of the Tor Browser that was downloaded was outdated (version 7.5) compared to the real current release (version 9.0 at the time of the attack). Additionally, it had disabled the digital signature check for installed Tor Browser add-ons (xpinstall.signatures.required was set to false). The updater tool was also renamed to prevent victims from updating to a genuine version of the Tor Browser.
• While the browser used the Tor proxy, effectively anonymizing the user's IP address, user activities could still be monitored. This was due to a unique user-agent (a text-based identifier) being set, which revealed the software and operating system, thereby providing a unique browser fingerprint enabling network observers to track activities.
• The attackers had bundled the HTTPS Everywhere extension with a modified manifest.json file. This allowed the web extension to gain broader permissions and to introduce content scripts into various web pages. Consequently, a Command and Control server could load further scripts when users browsed certain Darknet markets and a popular Russian money transfer service (QIWI), substituting cryptocurrency wallet addresses to those controlled by the criminals, thereby facilitating theft.
• It is also speculated that the settings for the NoScript extension were altered to enable JavaScript when browsing.

hacked github.com

2012 Unauthorized GitHub repository write access.

GitHub disclosed a public key security vulnerability and mitigation following reports of unauthorized repository write access.

2014 Reported GitHub compromise (Homakov).

A follow-up write-up described another GitHub hack scenario and related discussion.

2022 Stolen OAuth tokens abused to access private repositories.

Mike Hanley, Chief Security Officer at GitHub, wrote in a blog post that compromised OAuth user tokens from Heroku and Travis-CI-maintained OAuth applications were stolen and abused to download private repositories belonging to dozens of victim organizations that were using these apps.

Lists of Attacks in the Wild

• Catalog of Supply Chain Compromises

See Also

• Placing Trust in Kicksecure
• OpenPGP
• signify
• Verify the images
• Download Security
• Kicksecure Signing Key
• Software Signature Verification Usability Issues and Proposed Solutions
• discussion: flatpak remote-add --from=https://….flatpakrepo relies on TLS CAs to bootstrap trust path

Attribution

Gratitude is expressed to Qubes OS (Permission). The What Digital Signatures Prove chapter contains content from the Qubes OS: What do the Digital Signatures Prove and What They DO NOT Prove page.

Footnotes

Download Issues Documentation Signing Key Previous page: Download Issues Index page: Documentation Next page: Signing Key

Kicksecure A secure by default operating system with the latest security research in place.

Dark mode

Follow us on social media

Supported by Power Up Privacy

Kicksecure is proudly supported until 2026 by Power Up Privacy, a privacy advocacy group that seeks to supercharge privacy projects with resources so they can complete their mission of making our world a better place. (Strictly subject to our sponsorship policy.)

At Kicksecure we value freedom and trust, supporting Open Source and Freedom Software

By using this website, you acknowledge you have read, understood, and agree to be bound by these agreements: Terms of Service, Privacy Policy, Cookie Policy, E-Sign Consent, DMCA, Imprint 2012- 2026 ENCRYPTED SUPPORT LLC

Your support makes
all the difference!

We believe security software like Kicksecure needs to remain Open Source and independent. Would you help sustain and grow the project? Learn more about our 14 year success story and maybe DONATE!